1. The Field of the Invention
The present invention relates generally to communications networks. More particularly, the present invention relates to systems and methods for interpreting the content of data frames that are present on a communications network.
2. The Relevant Technology
Computer and data communications networks continue to proliferate due to declining costs, increasing performance of computer and networking equipment, and increasing demand for communication bandwidth. Communications networks—including wide area networks (“WANs”) and local area networks (“LANs”)—allow increased productivity and utilization of distributed computers or stations through the sharing of resources, the transfer of voice and data, and the processing of voice, data and related information at the most efficient locations. Moreover, as organizations have recognized the economic benefits of using communications networks, network applications such as electronic mail, voice and data transfer, host access, and shared and distributed databases are increasingly used as a means to increase user productivity. This increased demand, together with the growing number of distributed computing resources, has resulted in a rapid expansion of the number of installed networks.
As the demand for networks has grown, network technology has grown to include many different physical configurations. Examples include Ethernet, Token Ring, Fiber Distributed Data Interface (“FDDI”), Fibre Channel, and InfiniBand networks. These and the many other types of networks that have been developed typically utilize different cabling systems, different bandwidths and typically transmit data at different speeds. In addition, each of the different network types have different sets of standards, referred to as protocols, which set forth the rules for accessing the network and for communicating among the resources on the network.
However, many of the network types have similar characteristics. For the most part, digital data are usually transmitted over a network medium via frames (also referred to as “data frames” or “data packets”) that can be of a fixed or a variable length. Typically, data frames have headers and footers on the two ends of the frame, and a data portion disposed in the middle. The specific layout of these data frames is typically specified by the “physical layer protocol” of the network being used. For example, the Ethernet physical layer protocol specifies that the structure of a data frame include a preamble field, a six-byte destination address field, a six-byte source address field, a two-byte type field, a data field having a variable size (46-1,500 bytes), and a four-byte error checking field. Other physical layer protocols will specify similar types of frame layouts.
As is well known, transmissions from one network connected device to another device are typically passed through a hierarchy of protocol layers. Each layer in one network connected device essentially carries on a conversation with a corresponding layer in another network connected device with which the communication is taking place and in accordance with a protocol defining the rules of communication.
For example, one well-known protocol standard is the Open Systems Interconnection (OSI) Model. OSI defines a seven-layer protocol model, which is widely used to describe and define how various vendors' products communicate. In that model, the highest network layer is the Application Layer. It is the level through which user applications access network services. The next layer is the Presentation Layer which translates data from the Application Layer into an intermediate format and provides data encryption and compression services. The next layer is referred to as the Session Layer, which allows two applications on different network connected devices to communicate by establishing a dialog control between the two devices that regulates which side transmits, when each side transmits, and for how long. The next layer, the Transport Layer, is responsible for error recognition and recovery, repackaging of long messages into small packages of information, and providing an acknowledgement of receipt. The next layer is the Network Layer, which addresses messages, determines the route along the network from the source to the destination computer, and manages traffic problems, such as switching, routing and controlling the congestion of data transmissions.
It is the next layer, referred to as the Data Link Layer, which packages raw bits into the logical structured data packets or data frames, referred to above. This would correspond, for example, to the Ethernet physical layer protocol noted above. This layer then sends the data frame from one network connected device to another. The lowest layer in the hierarchal model is the Physical Layer, which is responsible for transmitting bits from one network connected device to another by regulating the transmission of a stream of bits over a physical medium. This layer defines how the cable is attached to the network interface card within the network connected device and what transmission techniques are used to send data over the cable.
Thus, as a message is passed down through each of these respective layers, each layer may add protocol information to the message. Thus, the “data” present within the data payload of the data frame at the Data Link Layer (e.g., the Ethernet data frame) typically comprises a protocol stack comprised of multiple message packets. Each message packet has its own protocol format, and it may in turn be embedded within the data payload of another higher layer message, also having a different protocol.
As communication networks have increased in number and complexity, the networks have become more likely to develop a variety of problems, that are in turn more and more difficult to diagnose and solve. For example, network performance can suffer due to a variety of causes, such as the transmission of unnecessarily small frames of information, inefficient or incorrect routing of information, improper network configuration and superfluous network traffic, to name just a few. Such problems are compounded by the fact that many networks are continually changing and evolving due to growth, reconfiguration and introduction of new network typologies and protocols as well as new interconnection devices and software applications.
Consequently, diagnostic equipment, commonly referred to as “network protocol analyzers,” have been developed for capturing, analyzing, and displaying information about data frames that are transmitted over a network. Typically, protocol analyzers are designed to identify, analyze and resolve interoperability and performance problems in different networks typologies and protocols. For example, the equipment enables users to perform a wide variety of network analysis tasks, such as counting errors, filtering frames, generating traffic and triggering alarms.
To do so, a protocol analyzer typically has the capability to capture all of the physical layer data frames (packets) generated by other stations (nodes) on the network. The analyzer is then designed to evaluate the contents of each data frame and, preferably, display the contents along with a meaningful description, and preferably in the sequence in which they were captured from the network. Thus, a protocol analyzer typically includes a capture engine and a protocol decoder. The analysis data that can be displayed with each captured data frame can include a variety of information, including the time at which the packet was captured, the length of the packet, packet address information for one or more protocol layers, and a set of protocol decodes at each layer that the protocol analyzer is capable of decoding.
While protocol analyzers have proven to be extremely useful tools for debugging, testing and otherwise evaluating various operating characteristics of networks and network equipment, the implementation of such analyzers is difficult and previous approaches have not been entirely satisfactory. In particular, in order for the protocol analyzer to provide useful information for a given network, ideally it must be capable of interpreting each of the various—and sometimes numerous—protocols that are typically embedded within the physical layer data frame. The ability to perform this task is complicated greatly by the fact that today's communications networks utilize literally hundreds of different message protocols that may be present in any given data frame. As noted, a typical physical layer data frame on a network cable medium will have a data payload that is composed of multiple protocol layers. In fact, this “stacking” of message protocols within a physical layer data frame can often be more than five layers deep. Thus, today's protocol analyzer must be capable of interpreting and analyzing a myriad of different protocol types and combinations.
However, most protocol analyzers are specifically programmed to interpret and present a finite number of protocol types, and thus are limited in their ability to fully analyze all networks. The problem is exacerbated by the fact that new protocols are continuously being developed and existing protocols modified and updated. Thus, it has been extremely difficult for protocol analyzers to support all existing protocols, and it is difficult to update existing protocol analyzers to support new and modified protocols.
Typically, protocol analyzers are configured to support particular protocols by way of customized software. Specifically, the protocol analyzer is a programmable device (or is operatively connected to a programmable master device, such as a personal computer) that is programmed with dedicated program code addressed specifically to the interpretation and analysis of a protocol type. If a new protocol capability is needed, or if the existing protocol is changed, then the source code for the program must be modified, updated or rewritten and then recompiled in order for the analyzer to support the new protocol. When a change regarding the protocol capabilities of the protocol analyzer is to be made, the software developer obtains a protocol specification, written in a declarative format, studies the declarative protocol specification, and manually translates the declarative protocol specification to procedural executable code, written in a procedural language (e.g., C++).
Obviously, this approach of manually converting a declarative protocol specification into procedural executable code is terribly inefficient, and is costly and difficult to implement, since it requires software developers with significant knowledge of the details of a particular protocol. In addition, the program code is written in a single selected programming language, such as C++. Once the program code is developed using a particular programming language, it is difficult and expensive to write analogous code in other programming languages.
Thus, there is a need in the art to provide an efficient and flexible method for defining a protocol, and then generating the program code for analyzing it. The generation of programming code allows for the most efficient embodiment of a decoder. Such a method would require a minimal amount of manual work by software developers. In particular, the methodology should be able to be performed by anyone with familiarity with communications protocols, and not require advanced programming skills. Also it would be desirable if different program code could be generated with equivalent functionality, to suit the needs of different computing devices or computer operating systems. These and other needs are addressed by embodiments of the present invention.